Backing up a VM
A sample SessionToken will be used throughout this use case.
The sample SessionToken will be: e65aedeb-a0e7-440c-8309-1cc0bcd920dbBase URLs are required depending on the version of VM Backup being used. <base_url> for each version is:
V8.x: http://localhost:35113/api
V9.0.x: http://localhost:36015/api
V9.1.x: http://localhost:36013/api/rest
To start a backup, the AltaroVirtualMachineRef is required. This way, the API can be instructed which configured VM to back up. The following POST method starts a backup operation on the VM. The response will contain a Success value, which states whether VM Backup managed to start the backup operation. When this is false, it means that something went wrong while the API was processing the request, but before sending it over to the VM Backup Agent. When this occurs, it is generally due to an incorrect parameter, such as sending an AltaroVirtualMachineRef which does not exist. When the Success value is set to true, it does not mean that the operation is successful; it simply means that the operation could be processed by the API and could be successfully sent over to the VM Backup Agent.
<base_url>/instructions/take-backup/e65aedeb-a0e7-440c-8309-1cc0bcd920db/ba2e9cdc-0d85-48e6-8db7-a45c5a40819e
Whenever any kind of instruction is initiated, another API call can be made to check the status of the operation. This API call can either return the status of all the operation which are currently running, or it can return the status for one particular operation. Any call which starts an operation returns an OperationGuid, which can be located in the Data object. For demonstrative purposes, let us assume that the above take backup call returns the following OperationGuid:
OperationGuid: 1d005355-7d57-444b-b55b-393c1e0a4287
This GUID can be used from the time the operation starts, up until the operation finishes with either a success or an error. The following GET request uses the above OperationGuid to query the progress of the backup operation:
<base_url>/activity/operation-status/e65aedeb-a0e7-440c-8309-1cc0bcd920db/1d005355-7d57-444b-b55b-393c1e0a4287
As already mentioned, the OperationGuid can be omitted, and instead, all the statuses of all the operations which are currently running are returned instead:
<base_url>/activity/operation-status/e65aedeb-a0e7-440c-8309-1cc0bcd920db
When the above calls are requested, and no data has been returned, it means that the VM Backup Agent has finished processing the operation and has removed it from memory. There is a small time frame between the completion of the operation and the removal of the operation from memory. If the above calls are made during such time, the operation results are also returned. If this time frame has already passed, the result of the operation can alternatively be retrieved through the following GET request:
<base_url>/reports/backup/e65aedeb-a0e7-440c-8309-1cc0bcd920db/ba2e9cdc-0d85-48e6-8db7-a45c5a40819e
The above call returns the last operation details for that particular VM, both whether it was a successful or a failed operation.
While the operation is running, it can be aborted by providing the OperationGuid. This can be done by making the following POST request:
<base_url>/instructions/abort-operation/e65aedeb-a0e7-440c-8309-1cc0bcd920db/1d005355-7d57-444b-b55b-393c1e0a4287
The aforementioned process can obviously be applied to all the other instruction types, namely offsite copies, restores, seed-to-disks, sandbox restores and verification.
Note: A full list of available API commands can be found here